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FOREWORD 


This report covers those activities conducted under Study 2,3, 
System Cost/Performance Analysis, under NASA Contract No. NASW-2472 
from 1 September 1972 through 31 August 1973. The Aerospace Corporation 
Task Manager was T. Kazangey. The NASA Technical Director was 
R. R. Carley. The NASA review team consisted of the following persons: 

C, M. Akridge, W. S. Rutledge, G. E. Mosakowski, D. B. Clemens, 

H. Mandell, R. W, Abel, T. Campbell, and W. Little. 

The author acknowledges with gratitude the many individuals at 
The Aerospace Corporation who contributed to this effort. 
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1. INTRODUCTION 


As the space program matures into an applications industry, 
greater emphasis will be placed on improving the ability to predict the effect 
of program requirements on cost and schedules. Current advanced studies 
are estimating benefits for standardized subsystems and components, on-orbit 
servicing, and ground refurbishment of spacecraft, etc. Cost-estimating 
techniques that give greater insight earlier in the program cycle are required. 
As a step in this direction, this study was initiated to identify and quantify the 
interrelationships between and within the performance, safety, cost, and 
schedule parameters as delineated in Table 1-1. These data would then be 
used to support an overall NASA effort to generate program models and 
methodology that would provide the needed insight into the effect of changes 
in specific system functional requirements (performance and safety) on a 
total vehicle program (cost and schedule). 
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Table 1-1. Model Parameters 


1.0.0 PERFORMANCE 

1.1.0 Technical Characteristics 

1 . 1 . 1 

1.1.2 System peculiar; (i.e., no fewer than 

1.1.3 four items, no more than ten items) 
1. 1. 4 I 

1.2.0 Power 

1.2.1 Average 

1.2.2 Peak 

1. 3, 0 Weight 

1. 4. 0 Volume 

1. 5. 0 Vibration Specification 

1. 5. 1 Random (g rms) 

1.5.2 Non-random 

1. 6. 0 Temperature Specification 

1. 6. 1 Radiation 

1. 6. 2 Conduction 

1. 7. 0 Ambient Pressure Specification 
2. 0. 0 SAFETY AND HAZARDS 

2. 1. 0 Failure Assessment 

2. 1. 1 Failure rate 

2. 1.2 Number of single point failure 
locations 

2.1.3 Number of dual point failure 
locations 

2.2. 0 Failure Detection Probability 

2.3.0 False Alarm Probability 

2. 4. 0 Hazard Potential 

2.4. 4 Latent energy 
2.4.2 Radiation energy 
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Table 1-1, Model Parameters (Continued) 


3. 0, 0 COST 


3. 1. 0 

Design and Development 


3. 1. 1 Engineering 

3.1.2 Development 

3.2. 0 

Build and Checkout 


3.2.1 Tooling 

3.2.2 Manufacturing 

3.2.3 Quality control 

3.2.4 Clerical 

3. 3. 0 

Test Hardware 

3. 4. 0 

Training and Simulation 

3. 5. 0 

Support for 10 to 15 Years in Service Life 

3. 6. 0 

Management 

4. 0. 0 SCHEDULE (Time for Completion) 1 

4. 1. 0 

Proposal 

4. 2. 0 

Preliminary Design and System Analysis 

4. 3. 0 

Subsystem Analysis, Design, and Bread- 
board Testing 

4, 4. 0 

Prototype Design, Fabrication, and Test 

4. 5. 0 

Subsystem Production Engineering, 
Fabrication, and Testing 

4. 6. 0 

System Integration and Test 

4.7. 0 

Flight Test Phase (Flights 1 to 5) 

o 

CO 

Initial Operational Phase (Flights 6 to 2 0) 

4. 9. 0 

Operational Phase (Remaining Flights) 
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2. STUDY APPROACH 


The initial planning of the task divided the effort into six subtasks. 
The effort began with two subtasks. The first, development of flow charts 
of the design process, included a literature search and the initial develop- 
ment of modeling methodology. The second subtask developed background 
information on other modeling methodologies and on data bases. The remain- 
ing tasks included data development to collect properly formatted component 
data for sample calculations, refinement of the modeling methodology, the 
calculation of a sample case, and the preliminary modeling of other related 
subsystems . 

The attitude control system (ACS) was selected as the first space 
vehicle system to be used in the development of a modeling methodology 
described by such quantitative relationships. So that an early assessment 
of the modeling methodology could be obtained, the sample case was 
restricted to a single type of ACS to demonstrate the feasibility of the 
approach prior to a wider application. The actual modeling methodology 
selected for this study develops a consistent set of quantitative relationships 
among performance, safety, cost, and schedule, based on the characteristics 
of the components utilized in candidate mechanisms. These descriptive 
equations were developed for a three-axis, earth-pointing, mass expulsion 
ACS. A data base describing typical candidate ACS components was devel- 
oped, and sample calculations were performed on a digital computer. This 
approach, implemented on a computer, is capable of determining the effect 
of a change in functional requirements to the ACS mechanization and the 
resulting cost and schedule. If this modeling methodology is extended to 
other systems in a space vehicle, a complete space vehicle model can be 
developed . 

Section 3 reviews the development of background information and 
the modeling techniques considered that ultimately led to the cost/performance 
methodology developed under Task 2. 3. 
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3. BACKGROUND INFORMATION STUDY 


( 


At the start of the study, a review of potentially applicable cost 
modeling techniques was conducted. Included in this model review were the 
SAMSO/ Aerospace cost- schedule models, the General Electric Co. design 
guide for ACS, the Honeywell cost analysis, the Resource Data Storage and 
Retrieval (REDSTAR) data base, and the Optimized Design Integration System 
(ODIN) and Integrated Programs for Aerospace Vehicles Design (IPAD) 
Programs. The following paragraphs present a brief description of the 
material reviewed. 

Several distinct SAMSO/ Aerospace cost- schedule models were 
reviewed during the early stages of Task 2.3. These models are discussed 
in some detail in Section 2 of Volume U. In general, the models all use a 
cost estimating relationship (CER) approach to cost-out a specific type of 
system. Separate CERs are often used for each program phase, such as 
the design, development, test, and evaluation phase; first article production; 
and ongoing operations. In each CER, cost is related to some distinct physi- 
cal parameter such as weight or volume. Often a CER is developed using 
statistical least- squares regression on data obtained from previous pro- 
grams; these '’static" costs are distributed over time by a learning or 
improvement curve that takes into account reduced per-unit costs as produc- 
tion increases. In addition, inflation factors are usually included to account 
for reduction in purchasing power per dollar with increasing time. Finally, 
scheduling models are defined as a function of time and may run from 
simple, straight-line spreads to skewed variations of the normal distribu- 
tion curve. Various input and output formats are employed, with input 
requirements primarily set by the type of CERs used and with output formats 
determined by the level of output detail in the work breakdown structure 
(WBS) and by schedule resolution. 

In addition to the SAMSO/ Aerospace models, other models and data 
bases were reviewed. These include a General Electric design guide for 
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developing a satellite ACS, given mission requirements; the USAF 375 Series 
Manuals, which are structured along cost-accounting lines; and a Honeywell, 
Inc. cost analysis study. A portion of the Honeywell study consisted of a 
historical review of stabilization and control systems for Apollo, Gemini, 
and the F-104. An important conclusion of the Honeywell study was that an 
uncertain relationship exists between the weight of ACS space hardware and 
its cost. As mentioned previously, this relationship forms the basis of many 
CERs used by the space industry. 

Included in the development of background information were reviews 
of several approaches to data base formulation and management. The 
REDSTAR system was one of those considered. It was the result of a 1972 
fiscal year study, entitled Application of Engineering Cost Analysis , by 
Planning Research Corporation. 

The WBS used in REDSTAR is divided inconveniently for an ACS 
designer; it tends to scatter ACS elements through a number of categories. 
This lack of correspondence between the WBS and the attitude control func- 
tion does not mean that REDSTAR is not applicable to cost/performance 
modeling. However, a translation matrix, as developed in this study, would 
have to be used to interpret the WBS in a manner useful to a model that 
includes system performance as an integral part of its methodology. 

Several in-house data base systems used by The Aerospace Corpo- 
ration were also reviewed. Unfortunately, very little component data of the 

nature required for a cost/performance -oriented model of the type developed 
in this study were found. 

As the final task in development of background information, the 
N and IPAD Programs were investigated. The ODIN integrates computer - 
implemented models used for various aspects of system design and provides 
an optimum systems engineering approach to overall vehicle design. The 
AD supports the engineering design team by implementing, as much as 
possible, the computation and data management aspects of the design 

process. Conceptually, the Cost/Performance Model could be one module 
of the ODIN Program. 
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4. MODELING APPROACHES 


In the conceptual stage of Task 2. 3, effort was devoted to the initial 
formulation of an approach to cost/performance modeling. During this stage, 
a number of methodologies were conceived and required evaluation. The 
following criteria were formulated to judge each concept in a complete and 
objective manner and were used to evaluate the utility of each approach; 

a. A prime objective is to determine sensitivity of cost to changes 
in requirements. 

The modeling methodology must not impose a cumbersome 
reporting structure on the contractor. 

The modeling methodology must reflect costs from all 
phases of development through operations. 

The approach taken should reflect current design practice and 
tradeoff procedures. 

e. The model should achieve a balanced total vehicle design, 
considering total life -cycle costs in terms of performance, 
safety, and schedule requirements. 

In general, all modeling approaches considered can be subdivided 
into two basic categories. Bottom-up approaches, the first category, depend 
on development of a system design. Estimates of tasks, material costs, 
manpower requirements, and schedules are made at each identifiable level 
of system integration; total estimates are obtained by summing individual 
costs and schedules. 

Top-down models, the second category, are ess e ntiall^th^ C ER 
approach described previously. As CERs have been unsuccessful in meeting 
the prime criterion of determining cost sensitivity to program requirement 
changes, top-down approaches were judged unacceptable for a Cost/Perfor- 
mance Model. Further, it was thought that a model oriented from the bottom 
up could lead to fulfillment of the previously stated criteria. 

A model, called the "minimum" model, was hypothesized as a basis 
for development of a cost/performance methodology. The minimum model 
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considered, but did not adequately quantify, the performance, safety, cost, 
and schedule of an ACS. The "minimum" model was later expanded and 
became the Cost/Performance Model. Starting with functional payload re- 
quirements, a filter algorithm would be developed to determine an attitude 
control method to satisfy these requirements. Once the basic type of ACS, 
such as momentum storage, mass expulsion, or other applicable method,, was 
determined, various design configurations would be considered. 

Several models were examined in attempts to implement the mini- 
mum model. Details of two of these approaches and their applicability to a 
cost/performance modeling viewpoint are given in Section 3 of Volume II. 
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5 . COST/PERFORMANCE MODELING METHODOLOGY 


The modeling approaches reviewed did not provide quantitative 
relationships among the performance, safety, cost, and schedule parameters 
for an ACS. When both the top-down and bottom-up approaches were recon- 
sidered, it was decided that a Cost/Performance Model oriented from the 
bottom up could lead to a model employing quantitative expressions that would 
output performance and cost sensitivities. A set of basic equations, termed 
"aggregate equations, " was written to describe the performance, safety, 
cost, and schedule of the ACS in terms of the equipment used in a selected 
configuration. The equations were termed, "aggregate equations, " because the 
independent variables describing the ACS were "aggregated" into fundamental 
relationships to the elements of performance, safety, cost, and schedule. 

For example, the aggregate equation for the pointing accuracy of a three- 
axis ACS considers variables such as attitude sensor noise and misalignment, 
gyroscope drift and misalignment, signal processor noise, and control system 
deadband. Each of these variables is multiplied by a computed sensitivity 
coefficient and combined in a worst case and/or root- sum- square manner to 
form the aggregate equation for the ACS pointing accuracy. 

The Cost /Performance Model was developed using aggregate equations 
in conjunction with minimum model elements. The flow diagram from this 
model is shown in Figure 5-1. Starting with payload functional requirements, 
a filtering technique (search/sort/filter) is used to determine an attitude 
control method (such as a gravity gradient, mass expulsion control, momentum 
storage, or spin stabilization) that will satisfy the functional requirements. 

The selection of an attitude control method is made because each different 
ACS configuration has its own set of performance aggregate equations. Other 
relationships, such as the aggregate equations for safety, cost, weight, etc., 
remain unchanged or require only minor modifications, such as changing 
coefficients. Once a basic control method is determined, the type of equip- 
ment needed to mechanize the ACS can be selected by interation. Accessing 
a data base consisting of all ACS components suitable for this control method, 
the model first inserts the cheapest component into the pointing-accuracy 


5-1 




Figure 5-1. Cost/Performance Model 




aggregate equation, assuming low-cost ACS is our objective, and computes 
the pointing accuracy. If the pointing accuracy is poorer than desired, the 
model then selects the next least expensive set of components, iterating 
until the desired pointing accuracy is met. 

The next step is to use the safety aggregate equations to evaluate 
those hardware configurations that have met or exceeded the desired pointing 
accuracy requirement. The safety considerations consist of failure rate, 
failure detection probability, and the false alarm probability and hazard 
assessment (single point failures and TNT equivalent^). The failure rate 
^ggi^Ggate equation determines the necessary level (and configuration) of 
redundancy (and component quality) to satisfy the payload and mission reli- 
ability requirements. The failure detection and false alarm probability 
aggregate equations quantify the level of system monitoring (onboard or 
ground-based) needed to meet system success criteria. Those ACS hardware 
configurations that meet or exceed all safety requirements are recorded by 
the computer program. The power, weight, volume, thermal specification, 
vibration specification, and ambient pressure specification for the selected 
hardware configurations are then computed using the appropriate aggregate 
equations. Thus, for a given configuration, a set of applicable components 
is chosen (based for example, on minimum cost or on schedule requirements) 
from the data base. This configuration satisfies all the performance and 
safety requirements. After the set of applicable components has been 
selected, the centralization of major components is considered. For exam- 
ple, should the ACS use a centralized power supply or separate power 
supplies ? Also, the trade between centralized signal processing versus 
separate signal processing must be considered. Finally, the total ACS cost 
and schedule are predicted using the cost and schedule aggregate equations. 
This process may be iterated to meet cost or schedule requirements. One 
feature oi this aggregate equation approach is the ability to establish sensi- 
tivities to changes in functional requirements. One need only change the 
performance requirement (for example, pointing accuracy) and let the 
process iterate again to produce new results^ 

^The model only considers these parameters conceptually. 
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The following sections describe the major elements of the Cost/Per- 
formance Model, starting with the search/sort/filter technique that selects 
an attitude control method based on a set of performance requirements. 
Following the filter description, the aggregate equations and their relation-* 
ship in forming the Cost/Performance Model are discussed. 

A. SEARCH/SQRT /FILTER TECHNIQUE 

In the development of the search/sort/filter technique, the usual 
problem of attempting to find a system that meets certain requirements was 
inverted. The approach is based on the existence of only a finite number of 
attitude control methods. The problem is then worked in a manner to deter- 
mine what requirements are met or exceeded by each individual method. Once 
this information has been tabulated for all attitude control methods, sorting 
the possible attitude control techniques by searching through the search/sort/ 
filter matrix to find systems meeting the requirements is a straightforward 
problem. 

The input to the filter is based on ACS requirements originating 
from the character of the mission and the nature of the payload. The require- 
ments delineate orbital characteristics, spacecraft orientation, spacecraft 
performance, and general vehicle characteristics. For example, the mission 
and payload requirements determine the orbit of the spacecraft, the duration 
of lifetime of the vehicle, the nominal orientation, the attitude and attitude 
accuracy of the ACS, and the stationkeeping and reorientation requirements. 

ACS requirements derived from the basic mission and payload re- 
quirements are categorized, and, in general, multiple control methods may 
seem appropriate for a given set of ACS requirements. Therefore, a rationale 
is required to choose among the possible candidates. This rationale is pro- 
vided by functional requirements, with performance, safety, cost, and 
schedule providing quantitative criteria for tradeoff studies in the detailed 
analysis of the ACS. 

The output of the filter is the one or more control methods appropri- 
ate for the mission under consideration. For the Task 2.3 study, various 
attitude control methods are classified as active, semi-active, or inactive. 
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An active control method uses one or more feedback loops to main- 
tain the vehicle attitude within specified limits. Such a closed-loop system 
is completely self-contained by the spacecraft. 

An inactive attitude control technique directs the vehicle orientation 
by a passive feedback system. No sensors, control logic, or actuators are 
required by an inactive attitude control technique. 

The semi -active category covers all schemes that employ some of 
the elements of an active control technique. This may take the form of 
attitude sensors so that the spacecraft orientation may be estimated by 
ground-based data processing. 

In all, nine distinct types of attitude control were considered, in 
which inactive and semi -active configurations are possible for five of the 
attitude control techniques. Three methods employ active or at least semi- 
active control methods to provide stabilization. Finally, a method was 
included to cover those cases where multiple sources of control torque can 
be used successfully in concert (for example, combined gravity gradient and 
magnetic stabilization). 

B. AGGREGATE EQUATIONS AND FUNCTIONAL BLOCK DIAGRAMS 

■^gg^egate equations are the primary elements of the Cost/Perfor* 
mance Model; however, these equations depend on the particular ACS 
mechanization selected. Thus, as a starting point in the determination of 
aggregate equations, functional requirements are translated into functional 
block diagrams to determine general ACS mechanizations and associated 
equations. Next, centralization and redundancy would be con- 
sidered, leading to specific block diagrams from which more detailed aggre- 
gate equations are ultimately derived. 

Functional requirements are considered for the following four 

Type of Vehicle 

Unmanned, expendable, autonomous 
Unmanned, reusable, autonomous 
Manned, reusable, autonomous 
Manned, reusable, using ground support 


classes of vehicles; 

Class 

1 

2 

3 

4 
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Requirements for these vehicles are tabulated, and their functional 
AGS block diagrams are discussed for both coast and powered -flight phases. 
The aggregate equations for each ACS type that can be selected by the filter 
must be formulated and available to the Cost/Performance Model. Thus, 
following selection of a particular ACS mechanization by the search/sort/ 
filter, a specific set of aggregate equations would be selected. These 
equations quantitatively relate performance, safety, cost, and schedule of the 
mechanization. As a demonstration of how this is accomplished, aggregate 
equations are discussed in the context of their implementation as a digital 
computer simulation. This discussion is presented to aid illustration of the 
flow of information through the Cost/Performance Model and to provide a 
natural transition to the description of the Cost/Performance Simulation fol- 
lowing the discussion of aggregate equations. 

1. PERFORMANCE AGGREGATE EQUATIONS 

Aggregate equations were developed for a Tug -type vehicle with a 
three-axis mass expulsion ACS, using lio rizon scanners for pitch and roll 
reference and gyrocompassing for yaw reference. This particular type of 
mechanization is typified by the Agena vehicle. 

Vehicle attitude is sensed by a three -axis, body-mounted inertial 
reference unit containing integrating gyros referenced to earth coordinates 
by horizon scanning and gyrocompassing. Fixed attitude with respect to 
the earth is maintained by a pitch program giving the required orbital pitch- 
over rate. 

An illustration of a typical performance aggregate equation is the 
pitch attitude error equation. This equation is derived in Volume II and 
quantifies pitch attitude error in coast flight in terms of the control system 
deadband and errors associated with components such as the pitch gyro, 
horizon sensor, and electronics. If the instrument or component errors are 
known and stored in a computer -implemented data base, the pitch attitude 
error may be calculated and compared to an allowable error entered as an 
input to the computer -implemented Cost /Performance Model, Furthermore, 
the same sort of calculation and comparison could be performed for each 
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ACS channel and for each complete combination of sensors stored in the 
data base. Thus, if the data base contains information characterizing three 
distinct inertial measurement units (IMUs) and five horizon sensors, a total 
of 15 IMU/horizon sensor combinations would be available to implement the 
ACS, and each would have a distinct pitch channel attitude error as calculated 
by the pitch aggregate equation. 

The above described method of forming and evaluating ACSs is basic 
to the Cost/Performance Model. Only systems (combinations of data base 
components) meeting performance requirements are stored and subjected 
to further processing as defined by additional performance, safety, cost, and 
schedule aggregate equations. Additional performance -oriented processing 
includes calculation of propellant consumption, power, weight, or vibration. 

Not all performance aggregate equation results are subject to an 
evaluation or comparison procedure. While ACS accuracy in a given channel 
is compared to an allowable error, system weight, power, or propellant 
consumption typically is merely calculated and stored as a characteristic 
descriptive of a specific ACS. These items often represent impacts on 
subsystems other than the ACS, and would provide information to other 
modules of an expanded Cost/Performance Simulation. Subsequent iterations 
would be performed to ensure a balance between the impact on various 
subsystems to ensure a balanced vehicle design, 

2. SAFETY AGGREGATE EQUATIONS 

As a result of satisfying certain performance aggregate equations, 
a finite number of ACS configurations are formed by the Cost/Performance 
Model, As the next step in processing these configurations, the safety 
aggregate equations are introduced. These equations are categorized as 
failure rate, failure detection probability, and false alarm probability 
aggregate equations. 

The failure rate equation is used to calculate the reliability of each 
ACS configuration. This calculation is performed at a module level, with 
the ACS viewed as consisting of four separate modules. The modules 
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considered are the sensor, processor, actuator, and energy source modules. 
Each identifiable ACS component is considered as an element of one of these 
modules. Thus, horizon sensors and IMUs would be categorized in the 
sensor module; computers or control logic, in the processor module; pumps, 
in the actuator module; and propellant tanks, in the energy source module. 
Failure rate information stored in the data base .for each component is 
extracted as needed by the Cost/Performance Model. These are combined 
by safety aggregate equations to form failure rates for each module of the 
first ACS configuration stored as a result of previous processing by per- 
formance aggregate equations. Module fail ure rates are combined by still 
other safety aggregate equations to calculate total ACS reliabultylor a 
given mission duration. 

Again, as in the previous performance aggregate equation processing 
scheme, the calculated reliability of each particular ACS configuration is 
evaluated against a specified or acceptable level provided as a model input. 
However, the ACS configuration is not discarded, as it was during perfor- 
mance evaluation, if it does not meet the specified reliability level. Instead, 
a search for the lowest reliability module is initiated. Upon identification, 
this module is paralleled by an identical unit, and suitable aggregate equa- 
tions are used to recalculate the system reliability. The evaluation and 
paralleling process continues until the lowest reliability module is triply 
redundant. If the system still does not meet the specified reliability, it 
is deleted from consideration as a viable single -string ACS, However, 
should it, at any time, meet or surpass the required input reliability level, 
aggregate equations are used to calculate system failure detection and 
false alarm probabilities. In addition, system characteristics such as 
weight, volume, and total component cost are updated and stored. These 
items must be updated in case the paralleling process has changed ACS 
total system characteristics. This process continues until each ACS stored 
as a result of meeting performance requirements has been processed. 

The safety aggregate equation procedure described above essentially 
constitutes one -third of the total safety aggregate equation process. Follow- 
ing completion of the basic scheme, the whole procedure is repeated with 
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each ACS configuration mechanized, first as an active /standby (dual string) 

ACS, and then as a triply redundant ACS using voting. The terms "active/ 
standby" and "triply redundant" here refer to complete ACSs, in addition to 
modular levels of redundancy. For this reason, a separate set of safety 
aggregate equations is used for processing single- string, active /standby, 
and triply redundant systems. 

The possible number of acceptable ACS mechanizations following 
safety aggregate equation processing is triple the number of systems that 
successfully passed the performance aggregate equation process. This fact 
is accounted for in the computer -implemented Cost/Performance Model, 
by keeping track of three complete sets of system characteristics for each 
ACS configuration originally meeting or surpassing performance requirements. 

Details of safety aggregate equations and flow charts depicting the 
processing schemes discussed above are presented in Volume II. 

3. COST AGGREGATE EQUATIONS 

Two costing techniques are presented in Volume II. The first 
develops cost aggregate equations, using a data base structured in a manner 
siniilar (but not identical) to the REDSTAR data base mentioned previously. 

This technique results in six cost categories, each described by an aggregate 
equation that is a function of various labor rates, task man-hours, material 
costs, and the number of specific items required, such as engineering drawings. 
Summation of costs for each category determines the total cost of the ACS. 

These cost aggregate equations, to be a useful tool, require data in a very 
detailed WBS format. Unfortunately, such data generally are not available 
^util a design has progressed into its intermediate phase. An alternate com- 
ponent costing technique was therefore developed to calculate costs in the 
very early design phase. This alternate technique, described below, is the 
one used in the cost/performance computer simulation. 

The component cost approach, which is the second costing approach, 
develops cost aggregate equations based on the cost of ACS components 
selected via the performance and safety aggregate equations and requirements. 
This costing technique requires each ACS component to have non-recurring 
and recurring cost information as part of its data base. This cost information 
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is available from the REDSTAR data base. Aggregate equations then sum 
^ ^ r^^-tcrial costs for each compon©nt used, in si spocific ACS 
mechanization to determine total non-recurring material costs for each pro- 
gram phase, such as the design and development or the build and checkout 
phase. The form of the non-recurring material cost aggregate equation is a 
sum of the non-recurring costs of the ACS components, multiplied by an 

inflation factor. Phase costs are then summed to determine total non-recurring 
material costs. 

ACS non-recurring systems engineering cmTtT are “defined as a ~ 
function of total non-recurring material costs, and the material and systems 
engineering costs are finally summed to give total ACS non-recurring costs. 

Total recurring cost aggregate equations are structured in much 
the same manner as the non-recurring cost equations. Finally, ACS total 
costs are obtained by adding recurring, non-recurring, and management 
costs, where management cost is a percentage of total ACS cost. If more 
than one ACS is produced, a learning curve is used to account for reduced 
unit cost as additional units are built.. 

4. SCHEDULE AGGREGATE EQUATIONS 

Schedule aggregate equations determine the amount of seri^ tirrTe 
required to develop an operational ACS. This determination is accomplished 
by dividing the life cycle of the system into nine phases, beginning with the 
proposal phase and ending with the operational phase. Aggregate equations 
then describe each phase time in terms of the manpower available to 
complete a specific phase. 

So that required manpower can be estimated, manpower aggregate 
equations are formulated, based on activities associated with each phase. 
Schedule analysis matrices and flow charts are used as a master list from 
which to select pertinent activities. The charts and matrices take into 
account various schedule parameters, such as sequence constraints, man- 
loading limitations, production quantity, production rate, and delivery span. 
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6. COST /PERFORMANCE SIMULATION 


This section presents a brief summary of the Cost/Performance 
Simulation to show the manner in which aggregate equations interact with 
the cost performance data base and among themselves. 

Figure 6-1 presents an overview of the ACS Cost/Performance 
Simulation. The flow is the same for batch process operations as for on- 
line terminal operation. 

As depicted in Figure 6-1, entry of model variables and matrices 
initializes the program. A complex data base results from the many inputs 
required to define various ACS components. Therefore, the program is 
structured to allow entry of a stored data base, followed by easy program 
data base modifications or additions. 

The data base actually implemented is the Table 1-1 data base 
presented in detail in Section 6 of Volume II. It is essentially a list of all 
components available to configure various types of ACSs, with each component 
described in terms of parameters required as inputs to performance, safety, 
cost, and schedule aggregate equations. 

Following the first initialization phase, consisting of data base 
entry and modification, data are provided for the various performance, safety, 
cost, and schedule criteria to be used in the program during execution. For 
example, performance criteria (such as the required coast flight attitude 
control accuracy in roll, pitch, and yaw axes) are the inputs during this 
second phase of the program initialization procedure. These inputs are 
used to evaluate acceptability of specific ACS configurations as described in 
the discussion of aggregate equations. A similar input would specify a 
required ACS mission success probability, and set a criterion for acceptance 
of each candidate ACS configuration during program execution of safety aggre- 
gate equations. Final inputs prior to program execution provide sort criteria 
that will format program outputs by ranking acceptable ACS configurations 
according to cost, reliability, accuracy, or any other criterion calculable, 
using aggregate equations implemented in the simulation. i 
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As described previously, the safety aggregate equation module 
immediately follows implementation of the performance module in the 
sequence of operations performed during execution of the Cost/Performance 
Simulation. All ACS configurations that have successfully passed perfor- 
mance criteria and are stored in the answer matrix are screened by the 
Safety module, as indicated in Figure 6-1. Those single -string systems 
not meeting reliability criteria are upgraded by paralleling the lowest 
reliability module in the ACS sensor, processor, actuator, energy source 
module string. The total reliability of the improved system is then recalcul- 
ated and checked for compliance with reliability specifications. If the system 
is still unacceptable, paralleling of the weakest module continues. (The 
weakest module may or may not be the same module paralleled previously. ) 
This process is continued until the system is acceptable, or until a module 
exceeds triple redundancy, at which point the program rejects the con- 
figuration as unacceptable in a single -string mechanization and proceeds to 
evaluation of the next configuration. Should the system meet reliability 
criteria, failure detection probability and false alarm probability are cal- 

for the configuration, and the system is stored in the answer matrix 
as an acceptable single -string mechanization. 

After all configurations stored in the answer matrix have been 
evaluated for compliance with reliability criteria when mechanized as a 
single -string ACS, the program proceeds to evaluate each configuration in 
an active /standby ACS mechanization. As before, paralleling of modules is 
allowed to upgrade reliability of the active /standby mechanizations, and in- 
dividual modules are held to maximums of triple redundancy. Systems 
meeting reliability criteria have failure detection and false alarm probabilities 
calculated, and are then stored in the answer matrix as an acceptable active/ 
standby mechanization. 

Following evaluation of all answer matrix entries as active /standby 
mechanizations, the program evaluates each entry in the answer matrix 
mechanized as triply redundant ACS with voting. In this sample mechaniza- 
tion, upgrading of individual modules by paralleling is not allowed, as the total 
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ACS is already triply redundant. Other calculcations proceed much as 
described for previous mechanizations, and detailed flow charts of the 
procedures described above are provided in Section 5 of Volume II. 

Configurations not meeting reliability criteria after safety module 
processing are deleted from the answer matrix, and the program proceeds 
to processing of schedule and cost aggregate equations. 

Upon completion of the ACS requirements phase of initialization, 
the program begins execution of performance aggregate equations and decis- 
ions. 

In the performance module of the Cost /Performance Simulation, 
the acceptability of each candidate ACS is evaluated by comparing calculated 
ACS performance, as determined by performance aggregate equations, to 
required ACS performance parameters entered during program initialization. 
The flow of calculations in this module may be relatively simple, such as 
those shown in Figure 6-1, or they may be more complex and essentially 
represent a basic error analysis of a particular ACS configuration. In 
general, use of the simulation during early conceptual phases of a program, 
would rest on several baseline ACSs, with each specific baseline defined by 
a separate set of aggregate equations. Later applications could be based on 
a single ACS configuration requiring a single set of performance aggregate 
equations. The program is structured to accept these intermodule changes 
without disrupting the basic intramodule interactions that form the basis of 
the Cost/Performance Simulation. 

Regardless of the level of sophistication of the performance aggregate 
equations, all ACS configurations passing the performance criteria are 
stored in the answer matrix. This matrix maintains a dynamic record of 
the characteristics of ACS configurations that have met or surpassed 
criteria entered during program initialization, such as total ACS weight or 
an identifier of a particular data base component that is a part of a specific 
ACS configuration. 

Schedule ,ind cost calcxilations a re a straightforward implementation 
of the schedule/cost aggregate equations; however, the present sample program 



3oes not implement schedule equations. Present plans call for presenting 
schedule results as charts showing major program milestones for each 
configuration stored in the answer matrix. Each chart would be keyed 
to the printout of other information for the particular configuration that it 
represents; the total package represents complete assessment results of all 
ACS configurations meeting performance and safety criteria. For ease in 
evaluating various ACS configurations, printouts are ordered according to 
the particular criteria entered by the operator. 
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7. INTERACTION WITH OTHER SUBSYSTEMS 


The interaction of the ACS with sonae of the other subsystems was 
briefly considered, A generalized guideline for the development of a power 
conditioning system for the ACS is given in Section 7 of Volume II. The 
major thermal drivers that influence the design and operation of typical ACS 
components are identified in Section 8 of Volume II. The nature of the 
requirements placed on the ground support equipment (GSE) by the ACS is 
discussed in Section 9 of Volume II. 
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8. COST /PERFORMANCE MODEL SAMPLE 
CALCULATION-CER COMPARISON 


Figure 8-1 compares sample calculations of the Cost/Performance 
Simulation with a cost- versus -weight CER developed at SAMSO. The Cost/ 
Performance Simulation output of cost versus weight for a three-axis ACS is 
consistent with the cost-versus -weight CER developed at SAMSO. CER 
results were obtained by summing DDTE costs, with first article cost adjusted 
by a learning curve to obtain the cost of 20 systems. These results were 
obtained using a data base consisting of three distinct horizon sensors, three 
star references, and three IMUs. This gives a total of 27 unique ACS com- 
ponent combinations or 81 ACSs, counting single- string, active/ standby, and 
triply redundant mechanizations. 

Figure 8-2 shows the cost -versus -reliability relationship for the 
same 20 systems. Details of this and other simulation results are given in 
Appendix C of Volume II. 

It is concluded, based on the curves of Figure 8-1, that Cost/ 
Performance Model results are in substantial agreement with results 
obtained using conventional approaches. However, the Cost/ Performance 
Model provides a more detailed insight and a potential for accomplishing 
sensitivity studies, using up-to-date data bases, and for performing trade 
studies between various subsystems unobtainable using conventional 
approaches; it also indicates regions where components are not available. 
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9. CONCLUSIONS AND RECOMMENDATIONS 


A viable cost/performance modeling methodology was developed, 
which quantified the interrelationships among performance, safety, cost, 
and schedule for an ACS by means of "aggregate equations." This method- 
ology is designed to be applicable to all phases of a project. As the design 
progresses, the model and the supporting data base may be updated with 
more definitive information. A sample case of the model was implemented 
on a CDG 7600 computer for a three-axis stabilized, earth-pointing, mass 
expulsion ACS. In its computerized form, the model will aid the designer 
in evaluating trade studies, and will simplify the achievement of a balanced 
system design, since the impact of ACS requirement changes on the other 
space vehicle systems and on the total vehicle can readily be determined. 

This model will also be useful for evaluating the effect of new technology 
or standardized components, by making suitable entries in the data base 
representing proposed component characteristics. 

Example calculations were run for several performance and safety 
requirements, using a sample data base. For these restrictive cases, the 
model results are consistent with conventional cost- versus-weight CERs. 

At the same time, the model can provide insight into the effect of many 
variables on system cost; this capability is not available using conventional 
CERs. For a specific system. Figure 8-1 shows the typical results for weight 
versus cost of development and a 20-unit purchase of ACS units; Figure 8-2 
shows the cost-versus-reliability relationship for the same 20-unit basis. 

This model emphasizes the fact that there are discrete cost/weight points 
with some significant gaps. 

As a result of successful preliminary development of this Cost/ 
Performance Model, further work should be undertaken to 

a. Develop aggregate equations for other ACS methods, other 
space vehicle systems, and support systems (e.g., GSE 
ilight operations) as a step toward developing a vehicle 
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b. Refine the existing aggregate equations, especially for 
parameters such as power, weight, volume, specifications 
and schedule. 

c. Consider centralization and hazards quantitatively. 

d. Continue development of the data base to support this model. 

The model presently provides a means of determining a unified 
estimate of performance, safety, cost, and schedule on a single type of 
ACS for the use of both performance and cost analysts. With refinement 
of some aggregate equations and extension to other ACS types, this model 
will be applicable to trade studies concerning most ACS requirements. 
Similarly, it can be applied to other space vehicle systems as the required 
aggregate equations become available. If fully developed, the model will 
provide a single tool for determining a unified estimate of performance, 

safety, cost, and schedule for a vehicle that supports both cost and perfor- 
mance analyses. 


It is recommended that the fiscal year 1974 effort include exten- 
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base to be acceptable for both performance and cost analyses; testing of the 
capability of the model to predict space vehicle interrelationships; and a user 
review to evaluate the potential of the model to assist in programmatic change 
control, such as configuration management. 
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